Skip to content

Add imxrt118x architecture and imxrt1180-evk board configurations - #20114

Open
jlaitine wants to merge 23 commits into
apache:masterfrom
tiiuae:add_imxrt118x_architecture
Open

jlaitine wants to merge 23 commits into
apache:masterfrom
tiiuae:add_imxrt118x_architecture

Conversation

@jlaitine

@jlaitine jlaitine commented Sep 11, 2026

Copy link
Copy Markdown
Contributor

Summary

I have started working on imxrt1180-evk support. This PR adds architecture support under arch/imxrt and boards.

Some drivers have been ported from imx9 (trdc, ele, dma), some copied and later modified from imx9 (clock configuration), some using imxrt drivers directly (peripherals: usb, lpuart, spi,, i2c...).

There are three board configurations available:

imxrt1180-evk:bl: bootloader on m33

  • generates "flash.bin" to be flashed to offset 0 on qspi nor
  • loads ele firmware, configures ele & trdc
  • configures m7 power mode (HSRUN) and clocks (798 MHz for M7, 266MHz for M33)
  • releases m7 to run at 0x80000

imxrt1180-evk:nsh: nsh image for m7 core.

  • generates "nuttx.bin" to be flashed to offset 0x80000 on qspi nor (compatible with the bl above)

imxrt1180-evk:nsh-m33: Plain nuttx nsh image on m33

  • does the same as "bl", but just runs nsh, leaves m7 to be

Impact

Doesn't (shouldn't) impact existing targets. Only adds support for new board

Testing

Very little testing so far. Both configurations ("m33 bl + m7 nsh" & "m33 nsh") boot and appear stable.

What seems to work:

  • clock&power configurations, interrupts, GPIO, DMA3/4, LPUART.
    What almost works:
  • USB usbdev + cdcacm works from m33, but not on m7 yet, not debugged why
    Compiles, not tested:
  • SPI&I2C

Update:

Tested both "nsh-m33" and "bl+nsh" configurations with ostest. Also tested USB CDCACM on both m33 and m7 nsh images.

Ostest reports:

m7_testing.txt
m33_testing.txt

@jlaitine
jlaitine force-pushed the add_imxrt118x_architecture branch from 3e980e6 to cdd0d6f Compare September 11, 2026 10:14
@github-actions github-actions Bot added Area: Build system Arch: arm Issues related to ARM (32-bit) architecture Arch: arm64 Issues related to ARM64 (64-bit) architecture Size: XL The size of the change in this PR is very large. Consider breaking down the PR into smaller pieces. Board: arm labels Sep 11, 2026
@jlaitine

Copy link
Copy Markdown
Contributor Author

And also the topmost patch is actually not related to this port. It was just something I came across while debugging some uart/dma issues. Need to test & submit that separately

@github-actions

github-actions Bot commented Sep 11, 2026

Copy link
Copy Markdown

MemBrowse Memory Report

No memory changes detected for:

#include "hardware/imxrt_dmamux.h"

#ifdef CONFIG_IMXRT_EDMA

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe add a comment on what eDMA ver3 entails, being eDMA3+eDMA4 for IMXRT118X.

* Included Files
****************************************************************************/

/* Minimal bootloader application for releasing the Cortex-M7. */

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure if this belongs to a board, I would rather have something like under the arch guarded behind a kconfig, so other imxrt1180 based boards can use it as well avoiding code-duplication. You might have split up this logic.

@PetervdPerk-NXP

Copy link
Copy Markdown
Contributor

Hi Jukka,

Thanks for your contribution. It’s looking very good, and you’ve integrated it nicely into the existing i.MX RT family. I’ve added a few comments, but overall, the implementation looks solid.

Unfortunately, I don’t currently have time to test the code on a board myself. When I have the opportunity, I can try it on an https://www.nxp.com/design/design-center/development-boards-and-designs/FRDM-IMXRT1186. Do you have a FRDM-IMXRT1186 board yourself as well? Otherwise I can maybe ask around to get you a sample.

@jlaitine
jlaitine force-pushed the add_imxrt118x_architecture branch from cdd0d6f to 905d4ba Compare September 11, 2026 12:25
@jlaitine

jlaitine commented Sep 11, 2026

Copy link
Copy Markdown
Contributor Author

Thanks @PetervdPerk-NXP for your comments! I'll fix those things when moving forward. For the "bootloader" I wasn't sure where to place that. I will clean it up / split it somehow, and place the functionality under arch as you suggested!

I started debugging the usb on M7, and I believe I found a bug in the cache management in imxrt_usb. Have you had issues with that? The fix is now mangled together with 118x specific fixes in e6411a2

Basically, I think it is doing a cache invalidation with wrong address; I believe dtd->buffer0 shouldn't be used to invalidate the cache, but it should be done with the original buffer pointer stored in priv (the same way it is done in imx93 driver).

Have you had issues with imxrt USB + write back cached memory? With up_invalidate_dcache done only after the transfer using the original start pointer, the usb is working for me in both m33 (currently xcache off) and in m7 (dcache on with writeback).

There are some really unneeded fixes as well (added DEBUGASSERTS, and making many times sure that buffers are properly allocated...), but the main issue is really how the cache gets invalidated, not using the buffer0 in the middle of transfer, but only after the transfer using the original start pointer so that it doesn't invalidate past the receive buffer.

@jlaitine

Copy link
Copy Markdown
Contributor Author

Funny thing is, that there are now a lot of nxstyle errors from old code; the nxstyle itself has changed, I believe.

@jlaitine
jlaitine force-pushed the add_imxrt118x_architecture branch from 905d4ba to c8640f3 Compare September 11, 2026 12:52
@PetervdPerk-NXP

Copy link
Copy Markdown
Contributor

I started debugging the usb on M7, and I believe I found a bug in the cache management in imxrt_usb. Have you had issues with that?

I've had some DMA related issues with USB before on the i.MXRT106X family but I couldn't reproduce it easily and never happened on i.MXRT117X but that uses write-through cache, so indeed that bug could've been in there for like forever.

Funny thing is, that there are now a lot of nxstyle errors from old code; the nxstyle itself has changed, I believe.

Indeed it seems that they hardened the checks on switch statements had it with this simple fix as well PR #20117

@jlaitine
jlaitine force-pushed the add_imxrt118x_architecture branch from c8640f3 to ac56ed5 Compare September 14, 2026 07:06
@jlaitine
jlaitine force-pushed the add_imxrt118x_architecture branch 4 times, most recently from aa5b733 to 44388bd Compare September 14, 2026 13:28

@acassis acassis left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jlaitine please add Documentation to the arch and to the board.

@jlaitine
jlaitine force-pushed the add_imxrt118x_architecture branch 7 times, most recently from 0ec9315 to 5f85c13 Compare September 15, 2026 09:50
@jlaitine

Copy link
Copy Markdown
Contributor Author

Now removed the extra (old) README.md under boards, pointed out by @xiaoxiang781216

Add support for placing the primary ram into SysTCM on M33 cores or DTCM on M7

Signed-off-by: Jukka Laitinen <jukka.laitinen@tii.ae>
- Only submit and account for a wrapped second TX segment when scatter/gather descriptors
  are available. Without in-memory TCDs, submitting the second segment overwrites the
  active hardware descriptor and incorrectly advances the serial buffer past unsent data.
- Invalidate DMA RX buffer initially

Signed-off-by: Jukka Laitinen <jukka.laitinen@tii.ae>
Add imxrt118x memorymaps as hardware/rt118x/imxrt118x_memorymap.h

Assisted-by: Claude Code:claude-opus-4-8
Signed-off-by: Jukka Laitinen <jukka.laitinen@tii.ae>
Add interrupt numbering for imxrt118x in imxrt118x_irq.h, and support
for more interrupts in imxrt_irq.c and imxrt_clrpend.c.

The interrupt numbers are generated from the Reference Manual by AI

Assisted-by: Claude Code:claude-opus-4-7
Signed-off-by: Jukka Laitinen <jukka.laitinen@tii.ae>
i.MXRT118x have a Cortex-M33, which is ARMv8-M. Add cache line definitions
for this one.

Signed-off-by: Jukka Laitinen <jukka.laitinen@tii.ae>
Port the ccm / clock configuration from iMX93 to iMXRT118x.
Register definitions are generated from RM using AI

Assisted-by: Claude Code:claude-opus-4-7
Signed-off-by: Jukka Laitinen <jukka.laitinen@tii.ae>
…controller

Add a header file defining the imxrt118x GPC registers

Assisted-by: Claude Code:claude-opus-4-7
Signed-off-by: Jukka Laitinen <jukka.laitinen@tii.ae>
Add register definitions for IMXRT118x Analog-Digital top level block.

Assisted-by: Claude Code:claude-opus-4-7
Signed-off-by: Jukka Laitinen <jukka.laitinen@tii.ae>
Support reading the OCOTP via the shadow register on imxrt chips with integrated
ELE. On these chips, writing is done via ELE, this is not yet implemented.

Signed-off-by: Jukka Laitinen <jukka.laitinen@tii.ae>
Add IMXRT AONMIX register addresses and bit definitions in a separate header file
"imxrt118x_blkctrl.h".

The header is generated using AI from imxrt118x reference manual.

Assisted-by: Claude Code:claude-opus-4-7
Signed-off-by: Jukka Laitinen <jukka.laitinen@tii.ae>
The trdc driver has been copied from arm64/imx93, and modified to fit imxrt118x.

The relevant register definitions have been generated by AI from the RM.

Assisted-by: Claude Code:claude-opus-4-7
Signed-off-by: Jukka Laitinen <jukka.laitinen@tii.ae>
iMXRT118x uses the same security element as the imx93. Just add iMXRT specific
register definitions and port over the driver code.

Signed-off-by: Jukka Laitinen <jukka.laitinen@tii.ae>
…form

- Initialize the internal secure element, if configured
- Initialize the TRDC, if configured
- Disable the TCM enabling code when compiling for other than Cortex-M7 chip.
  This needs to be skipped for M33 core on imx118x

Signed-off-by: Jukka Laitinen <jukka.laitinen@tii.ae>
Add the definitions for the Inter-Peripheral Crossbar Switch for iMXRT118x

Signed-off-by: Jukka Laitinen <jukka.laitinen@tii.ae>
- Add imxrt118x compatible IOMUX definitions, named as IOMUX_VER3. This is the
same IP as what is used for example for IMX9. Instead of directly copying the support
from imx9, pack the padconfig into the same 32-bit value used for GPIO for easy use.

- Add imxrt118x compatible rgpio driver. This is the same GPIO block as what has been used
in imx9. Instead of directly copying the support from IMX9, add pin muxing directly
into GPIO driver as well, to keep the usage compatible with existing IMXRT boards.

Signed-off-by: Jukka Laitinen <jukka.laitinen@tii.ae>
- Small additions to existing drivers to support more UARTs
- Properly invalidate the cache over DMA RX buffer initially

Signed-off-by: Jukka Laitinen <jukka.laitinen@tii.ae>
- Move/make sure that ep0buf is in usb dma capable memory. Especially if
  .data/.bss are in TCM, the buffers need to be placed in another section.
  If the section .dmamemory doesn't exist, they will end up in .data like before
- change "#ifdef CONFIG_ARCH_FAMILY_IMXRT117x" into
  "#if defined(CONFIG_ARCH_FAMILY_IMXRT117x) || defined(CONFIG_ARCH_FAMILY_IMXRT118x)"
- In imxrt_epcomplete dtd->buffer0 must NOT be used to compute the data buffer's
  cache-maintenance address range. The hardware advances buffer0 (and its
  "current offset" low-order bits) as the transfer progresses, so by completion
  time it points *past* the start of the buffer (at start + xfer_len), not at
  the buffer itself. Instead, use the original privreq->req.buf when the transfer
  is complete.

Signed-off-by: Jukka Laitinen <jukka.laitinen@tii.ae>
Add a few !defined(CONFIG_ARCH_FAMILY_IMXRT118x) gates similar to 1176 to
buid the common drivers also for 118x variants.

Signed-off-by: Jukka Laitinen <jukka.laitinen@tii.ae>
- Add driver supporting the DMA3 and DMA4 in iMXRT118x chips. The driver is first copied
  from imx93, and then changed just the relevant parts (function names, clocking and
  irq handling) to match the imx118x configuration.
- Add the DMA channel numbering in hardware/rt118x/imxrt118x_dmamux.h from RM
  by claude.

Assisted-by: Claude Code:claude-opus-4-7
Signed-off-by: Jukka Laitinen <jukka.laitinen@tii.ae>
Add a function which can be called from M33 core on imx118x to start
executing on M7 core.

The function:
- Configures the M7 clock root
- Releases M7 from reset
- Asks the secure element to release the M7 (ENABLE_APC)
- Enables the M7 clock

The function is compiled in when a configuration flag
CONFIG_IMXRT_CM7_BOOT=y

Signed-off-by: Jukka Laitinen <jukka.laitinen@tii.ae>
We must enable the MPU on IMXRT118x to be able to keep writeback dcache on.

Signed-off-by: Jukka Laitinen <jukka.laitinen@tii.ae>
…urations

This adds the initial board configurattions for building NuttX for imxrt1189-evk.

The board boots on Cortex-M33 core, for which there are two m33 targets: nsh-m33 and bl.

- "bl" target does basic initialization of ELE and TRDC and just releases the M7 to run
  at 0x20080000.
- "nsh-m33" target just boots nuttx into nsh shell on m33

- The "nsh" target is for M7 core. It can be flashed at 0x20080000, and
  it boots to nsh shell with a proper bootloader on m33 (the bl target does this).

Signed-off-by: Jukka Laitinen <jukka.laitinen@tii.ae>
…80-evk

Add the documentation for the new supported board configurations and for the architecture,

Assisted-by: Claude Code:claude-opus-4-7
Signed-off-by: Jukka Laitinen <jukka.laitinen@tii.ae>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Arch: arm Issues related to ARM (32-bit) architecture Area: Build system Board: arm Size: XL The size of the change in this PR is very large. Consider breaking down the PR into smaller pieces.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants